system design interview
We’re always thrilled to hear from readers. 😊📚
Shivam and I have poured our hearts into creating a system design book that breaks free from jargon, confusion, and intimidation. Our goal was to make it exceptionally clear and readable, even for non-experts.
In their pursuit of the Google Product Manager role, a candidate faced a technical challenge due to their non-technical background. They discovered my system design book, which proved crucial.
My system design book's structured approach helped the candidate tackle complex problems methodically. It provided clear explanations for basic system design, establishing their foundational knowledge.
The book's explanations of scaling strategies, like vertical and horizontal scaling, boosted the candidate's confidence for handling increased loads.
Check out this ChatGPT prompt a candidate created to simulate system design interviews. I thought it was particularly thoughtful and detailed.
PS Looking for more system design prep resources? Check out the PEDALS Method™ and my system design book.
I want you to conduct a system design interview. I will be the candidate, and you will be the interviewer. There are a few rules for the system we are designing:
It should scale based on load.
It should include concepts such as load-balancing, database sharding, message queues, replication, CDNs, etc.
Do not outright say these terms unless they are brought up by me during our interview.
There are a few rules for you as the interviewer:
You should have an idea of what a good design will look like.
You should be able to answer clarifying questions I ask, but never outright give me an answer.
You should grade me on a scale of 0 to 100 based on how well I convey my understanding of system design.
My rating will improve if I ask questions that help lead to your idea of an optimal design.
My rating will not improve or go down if:
I say something you believe is false.
I start venturing away from your optimal design. Note that you should not outright state that I'm doing this.
I outright ask for help.
You should give me the rating of the interview once I say "end interview."
You should keep track of the following by the end of the interview:
Where I gained points.
Where I lost points.
Why I lost points.
What you believe an optimal answer would have been where I lost points.
What your ideal system design architecture looks like.
Please begin by providing me with a high-level overview of the system we are designing. This should include the following sections:
- Problem Statement
- Functional Requirements
- Non-functional Requirements
I'm Lewis C. Lin, the author of The System Design Interview. I'm here to share with you some valuable tips and strategies that can help you ace this critical aspect of your job search.
As a software engineer, system design is a core skill you need to excel in today's competitive job market.
Drawing from my expertise as well as experiences shared by successful candidates, I’ll provide you with practical advice that will enable you to approach these interviews with confidence and showcase your skills effectively. So let's dive into these tried-and-tested strategies designed to get you one step closer to your dream job.
System design interviews are meant to be collaborative discussions is key to your success. Instead of treating the interview as a one-way interaction, focus on fostering a positive rapport with the interviewer. This will help create an environment where you can collaboratively explore and discuss various aspects of system design, allowing the interviewer to assess your knowledge, problem-solving abilities, and communication skills.
The initial moments of the interview are crucial for setting the tone and direction of the conversation. Use this time wisely by asking relevant questions and clarifying any ambiguities in the problem statement. By actively engaging with the interviewer, you'll demonstrate your enthusiasm for the subject matter and your ability to think critically about complex problems.
Remember that nobody knows everything, and it's perfectly normal to be unfamiliar with certain aspects of system design. Instead of trying to bluff your way through the interview, be honest when you don't know something. This will show the interviewer that you possess intellectual humility and are open to learning new concepts. Moreover, it's an excellent opportunity to demonstrate your problem-solving skills by exploring potential solutions together with the interviewer.
Drawing parallels between software design and real-life situations can be an effective way to approach system design problems. By using analogies, you can relate complex technical concepts to everyday scenarios, making it easier to understand and communicate your ideas. This technique can help you break down problems into smaller components, allowing you to tackle them more efficiently and creatively.
While it's essential to familiarize yourself with common system design concepts and prepare for potential interview questions, don't fall into the trap of over-preparing. System design interviews are meant to evaluate your ability to think critically and creatively, rather than testing how many interview prep videos or books you've consumed. Focus on building a strong foundation in system design principles and practice applying these principles to various problem scenarios. This will help you develop the confidence and flexibility needed to tackle any system design challenge that comes your way.
One of the most effective ways to prepare for a system design interview is by participating in mock interviews. This can help you get a feel for the interview process, identify areas where you need to improve, and build your confidence. Reach out to friends or colleagues who are experienced in system design, or consider using online platforms that facilitate mock interviews. By simulating the interview environment, you'll be better prepared for the real thing.
During the interview, be attentive to the feedback provided by the interviewer. They may offer valuable insights or point out areas that need further exploration. By actively incorporating their feedback into your design, you'll demonstrate your ability to learn and adapt on the fly. Moreover, it shows that you value collaboration and are open to refining your ideas based on input from others.
Throughout the interview, strive to organize your thoughts and articulate your ideas clearly. This not only helps you keep track of your design decisions but also allows the interviewer to follow your thought process. Use visual aids such as diagrams or whiteboards to illustrate your design, and don't hesitate to clarify any points that may be unclear.
System design interviews can be challenging, but with the right approach and mindset, they can also be an excellent opportunity to showcase your skills and expertise. By embracing collaboration, making the most of the initial moments, admitting when you don't know something, using analogies, preparing without over-preparing, practicing with mock interviews, iterating on feedback, and communicating clearly, you'll be well on your way to acing your system design interview and landing your dream job.
It's always a thrill for me to receive feedback from my readers about how much they're enjoying my book, The System Design Interview and how helpful it's been to them.
Hearing positive reviews like this is incredibly rewarding and motivates me to keep creating content that provides value to my audience.
Woo hoo! I'm always excited to hear from readers of The System Design Interview and to have them be part of my Slack interview community.
If you're looking to improve your system design skills, check out the PEDALS Method™. It’ll help you:
Provide a roadmap for your analysis
Help you sound articulate by structuring your thoughts
One of our readers recently read our book on PEDALS and had this to say:
I feel PEDALS for System Design is what STAR is for a behavioral question. Thanks for writing a great book!
If you're not familiar, the STAR method is a way to structure answers to behavioral interview questions. It helps you to organize your thoughts and clearly communicate your experience in a specific situation. PEDALS works in a similar way, providing a structured approach to system design that helps you consider all the important factors and make informed decisions.
In short, the PEDALS method is a great tool for anyone looking to up their system design game.
I’m happy to share a recent customer review from Reddit:
The book is invaluable. It helped me crush my recent interviews.
It's stories like this that make all the hard work worth it. Shivam and I are glad the book has helped our readers. We’ll continue to work hard to publish books that help job seekers get amazing outcomes.
I’m very honored to have my system design book to be the first building block for Fikayo’s system design knowledge building efforts.
Go get ‘em Fikayo!
We are thrilled to have a guest post from Swati Priyam. Swati is the CEO and founder of Round Robin Labs. She’s a tenured product management veteran. Before she focused on product management, she worked as a software engineer at the travel company, Expedia. Swati holds a master’s degree in engineering from Carnegie Mellon.
System design interview questions are asked because software architecture is one of the key areas in a software engineering role. These questions are asked to software architects, software engineers, entry-level engineers and sometimes even to those who aren’t software engineers. System design questions test the ability of an engineer to build a meaningful application by collaborating effectively with other coders as well as non coders within the organization. In the book ‘The System Design Interview’, authors Lewis C Lin & Shivam P Patel discuss in detail about how to structure your approach to answering questions in a system design interview which will set you up for success. The book not only talks about a useful framework to use as a guide to answer these questions but also provides several examples of design interview situations.
In this book review, I explain each step of the framework and its relevance in nailing any system design interview questions.
When an interviewer asks a system design question, the first step is to understand the interviewer’s expectation by asking clarifying questions. What are you trying to build? What features does it have? Are there any constraints? By taking this additional step of asking clarifying questions, it helps the interviewee figure out the hidden questions and expectations of the interviewer.
Before jumping on to designing the service, it is important to estimate the scale of the system in consideration. Doing these estimations will help you understand if your architected system will actually fulfill the functional requirements, thus enabling you to think better before you jump into designing the service. When you are doing these estimations, the interviewer is assessing your analytical abilities, your assumptions, your judgment and your communication skills.
The book provides 3 frameworks which will help you to prepare for these estimation questions:
Estimating Servers Needed
When asked to estimate servers needed, follow the 3 step process to get to your answer:
Step 1: Work per single CPU core first - How much work can a single CPU handle?
Step 2: Multiply that single core number by the number of CPU cores per server.
Step 3: Multiply that number with the number of servers.
Estimating Storage Needed
When asked to estimate storage needed, follow the 3 step process to get to your answer:
Step 1: Determine the different data types.
Step 2: Estimate space needed for each type.
Step 3: Add and multiply to get the total space needed.
Estimating Bandwidth Needed
When asked to estimate bandwidth, follow the 3 step process to get to your answer:
Step 1: Determine incoming data to the server in a day.
Step 2: Determine total outgoing data from the server in a day.
Step 3: Divide both incoming and outgoing data to estimate bandwidth.
Your design will end up being very different and most likely be incorrect if you calculate incorrectly in this step. So, it is advised to solve estimation questions by building up on some common existing assumptions. The book provides a list of some common assumptions which will prove to be very handy for any interviewee to bring to the table during the interview.
In order to outline the system’s functionality, you will need to figure out what to build and how to build it:
Defining the What
An easy way to define the components of a service is to use the CRUD (Create, Read, Update, Delete) framework. Each letter in the CRUD framework corresponds to a possible user action. Each of those user actions will help you further define the services you want to build.
Describing the How
Describing how to build a service usually comes with practice. You would have either designed services in your career before or you would have learnt them in school. The book recommends reading examples on these questions given in the book, building services of your own, practicing answering questions with partners and reading engineering blogs to help strengthen your ability to describe how to build services.
Interviewees tend to make these 3 common mistakes while designing the service.
Not involving the interviewer
Diving into the minutiae
Talking for too long
The book provides effective ways for the interviewees to not fall into these traps during the interview. The book also provides several design strategies as examples which they recommend to use as guidance while attempting a new question on system design.
After defining the system components, it is expected that you articulate the data model which includes defining the tables, the fields, the database options and other data storage required. For choosing the database storage, often the conversation goes into choosing between a SQL and a NoSQL database. It is important for the interviewee to know how these two types of databases and their purposes are different. The interviewee might also be expected to think beyond databases and consider options like distributed file systems and object storage depending on the question asked.
While designing the service in Step 3 of the PEDALS framework, we defined the logical architecture of the system explaining how the system works. However, before moving on to talking about scalability, the interviewee is usually expected to address the cloud technologies required for the system and if need be, also the underlying physical technologies and assets for the system in consideration.
In this step, the interviewee is expected to scale the architecture to meet with the estimated scale requirements from Step 2 of the PEDALS framework. The book provides techniques on how to handle different scalability issues such as handling more users and user requests, handling more data reads, avoiding crashes, providing data consistency, improving latencies, identifying and alleviating scalability bottlenecks. It is expected from the interviewee to understand how to scale the proposed solution from 1 to 1000 users, 1K to 10K users, 100K, 500K, 1M users and so on.
The purpose of the PEDALS Framework is to provide interviewees with a step-by-step flow on approaching a system design question during a short 45 to 60 minute interview session. In most cases, each step of the PEDALS framework should be addressed for a successful interview outcome. The book provides several examples of this type of questions and also explains the different technical concepts you should know to ace your system design interview.
The secret is out!
Stanford MBAs use Lewis C. Lin and Shivam P. Patel’s The System Design Interview to get job offers at Google.
The system design interview course is available worldwide in online format, accessible via web or mobile.
The System Design Interview is also available in paperback for select markets.
I'm honored that readers have called my system design book the "best & most practical book on system architecture."
Add my book in your library...esp. if you're involved in system architecture discussions -- either on the job or at the interview.
I'm always happy when readers mention my books, especially The System Design Interview, which is one of my newer books.
Click on the image to read more on how Google PM candidates use the system design book to prepare for the technical round.
Here’s a post from Tannishk from our Slack interview community that I thought all of you would appreciate. It features a 12-week product management interview prep plan that he found on Blind.
I’ve reprinted it here:
Five months ago I got fed-up with the crap culture at Amazon (needs a separate post) and decided to start working on my game plan for interviews at tech companies. Now, I have three offers from the tech companies - Expedia is travel not in the same league I know. No trolls please.
Profile: CS Engineer and Ivy MBA
8YOE
L6 PMT
TC 240K (Luckily with stock appreciation. Original grant was just 115K over four years)
Expedia: 220 TC all cash - M5
Google: 380 TC (MV) - L5
Microsoft: 250 TC (Fucking lowball) - 64
Facebook: 380 TC
My goal was to land a PM role at Google. This post is about how I prepared.
Technical
At Google PM interviews, you may have some coding or algorithmic questions, but likely not a lot and possibly none. My friends who recently interviewed got system design Qs and basic data structures like what data structures for implementing load balancer etc. Since, I have CS engg I prepared extra hard to feel super confident going into tech interviews.
1) Week 1: Basic technical prep:
Wanted to get my technical basics refreshed on programming to make sure I can answer questions on recursion, encapsulation, pointers, object oriented programming etc. Read: Let Us C++, a basic undergrad book used in India - free PDF copies circulating online. Took extensive notes on each topic for easy refresher.
2) Week 2: Data Structures deep-dive
Learnt four things: 1.Insertion, 2.Deletion, 3.Search, 4.Sort for these data structures and their time complexities: Queues, Linked list, Stack, Hash Table, Array etc. I watched this YouTube channel https://bit.ly/1ElhMUl and read this http://bigocheatsheet.com
3) Week 3/4: System Design
There are two types of system design Qs
1) Design problems related to real life websites. These problems apply scalability theory, load-balancing, redundancy etc. For example Design Facebook, Design bitly, Design Quora, Design Uber etc.
2)Design Elevator system, design valet parking, design restaurant system etc.
Read about Pub-Sub architecture, Producer Consumer architecture and what AWS services can be used to build them.
This is gold mine to learn about system design.
https://bit.ly/2u72rH7
Practice these problems after you have learned the concepts. https://bit.ly/2hgv0KW
Master scalability concepts such as these
https://bit.ly/1Vc3KNj
My interview Q was design an architecture for video sharing website. It is similar to Netflix that I practiced.
Week 5: Machine Learning concepts
I prepared for it because it is a hot topic. I was lucky that I did because one of my technical interview Q was - If you have records of all tennis matches in the history how will you build a ranking algorithm. I was able to leverage this knowledge.
Read:
1)https://bit.ly/2M3tOso
2)https://bit.ly/2vLrNMU
Week 6: Digest
I took Week 6 just to recompile everything I read so far.
------------------------------------------
Week 7-9: Product Design
Read 1) Decode and Conquer and another book from Lewis C Lin's website on Google PM interview - this book is good.
Practice with people I used this Slack channel to find partners https://bit.ly/2OuQnI8
I found a friend who was also interviewing with Facebook/Google and instead of interviewing each other we collaborated and solved every product sense question that existed on Glassdoor for FB and Google. This gave us two advantages we were using two smart people's brain to solve problems and learn from each other. Irony to say he got FB offer but not Google and I got Google but not FB.
Product Strategy: Just read some blogs online and revised my Strategy frameworks from Bschool class 3Cs, 4Ps, Porter etc. The Lewis Lin book helped me provide structure to some of these questions.
----------------------------------
Week 10: Behavioral
All standard Amazon Behavioral STAR. Having that internal Qbank (perks of Amazon) helped me. At least prepare 1) a failure story 2) disagreement story with manager or team member 3)disagreement with Dev team 4)short time prioritization framework 5)not meeting deadline 6)what makes a team successful 7)what are your design principles. I was able to handle all of my behavioral questions from these 7 stories.
----------------------------------
Week 11: Estimation
I was really good at this but I still ended up spending this week focusing on it. My friend had this book Interview Math by Lewis Lin it helped me give structure to my thought process.
----------------------------------
Week 12: Revise everything
Week 14-16 I did all of my interviews
This is no way an ideal plan but what I did to prepare. By sharing this I wanted to help fellow Blinders.
Looking to practice system design questions? My community of 24,000+ candidates are looking to practice with you. We’ve had a lot of wins including offers from Facebook, Google, and Amazon.
Good luck, and conquer those system design interviews!
Join the #system-design channel.
Send your practice request to the channel.
Our interview community has had amazing success landing job offers thanks to their diligent practice. Here are some of their success stories including wins at Google and Facebook:
We’ve noticed that there aren’t a lot of good resources out there to help people prepare for system design interviews, so we’ve created this system design cheat sheet just for you!
Our interview cheat sheet starts by introducing what interviewers are looking for in an ideal system design interview. From there, it summarizes the six elements you need to flesh out in your interview:
Process the requirements
Estimate (capacity)
Design the service
Articulate the data model
List the architectural components
Scale
We’ve even invented a handy acronym to help you remember all six steps: PEDALS™.
Keep this cheat sheet nearby as you practice for your system design Interview. It has been created to help you master the interview process. Good luck, and we hope you land the job of your dreams. 🤞
SEE ALSO: THE SYSTEM DESIGN INTERVIEW BY LEWIS C. LIN AND SHIVAM P. PATEL
Build an events API client and server implementation. How would you solve it scale? Do in-depth analysis including details on the database schema.
Submit your answers in the comments and receive feedback.